\section{Future Work and Reflections}
I will here mention and explain a few interesting things that I would
have liked to implement if I had the time to do it. 

\paragraph{Player elimination:} As of now, the way it works with the
MessageList is fragile and very susceptible to bugs and race
conditions. I really would have liked a more clean way of
impersonating a player as the referee such that there would be no
doubt as to which message comes from which protocol. This could for
instance be done by having a list of messages for each method in the
code. The current solution also obscures the code a bit, making it
harder to see what is happening at which point, but I am not sure
there is a workaround for this. Another problem I would address had I
the time, would be enabling a player to defend himself against the
referees accusation. Right now there is no obvious way of checking
what you send to a player, and especially not what you sent where the
receiving players log says the dispute was located at index $l$. All
in all, this should maybe have been the main focus to keep in mind
when I designed the system from scratch. Problems are not visible
though, until they are encountered.

\paragraph{Circuit and gates:} I would like to be able to handle large
amounts of gates as it is very frustrating being so close to showing
that a theory holds, but not be quite able to do it. A step the right
way at least, would be to throw out any gates that are evaluated and
no longer used by other gates. This could be implemented by having a
counter telling how many other gates pointed at you, and if this drops
to $0$, we delete it.

\paragraph{Cluster responsibilities:} In the heat of battle you
sometimes forget your overall idea, and in this case I forgot to keep
the responsibilities separate. The Player class was originally
intended to outsource as much of its work as possible, and just keep
track of what is send where. Instead it got to do a lot of
computations which could have been moved elsewhere. An example is the
public reconstruction protocol which is shared between the Player and
SharingProtocols.

\paragraph{DoubleShareRandom:} Here I implemented a ready check to
make sure everyone was synchronized. However, what I would have liked
to do was dispatch a separate thread to handle the check, since
knowing if you are unhappy or not is not going to be relevant until
the check would be complete anyway. This would eliminate the need for
synchronization, and save communication. 

To see how my proposed improvement to the protocol performs, I would
have liked to implement it with an option to enable/disable it if the
user did not think the setting was right for it.

\paragraph{Broadcasting:} I would also have liked to implement
broadcasting and Byzantine Agreement using synchronized clocks, but it
seems this would be a project in itself and not an easy task, so I did
not even consider doing it for this project. However, this is without
any doubt the largest step needed before a distribution to multiple
machines would work. Synchronized clocks removes the need for central
components which includes not only the Controller, but also the global
lock. As the players would then know exactly what data to expect, they
can become unhappy if they detect any messages received which does not
belong in this time frame. This could be multiple messages from the
same player and this could only happen if the sender is a corrupted
player, since an honest player would always send the correct values
and amounts of messages in any given time frame. The synchronized
clocks should thus also fix the race condition problems.

\paragraph{Memory leaks:} In order to have the possibility to run the
program with large numbers of players and multiplication gates, I need
to get rid of the memory leaks that happens both during the
preparation phase and computation phase. I can fix the computation
phase problems by applying the solution presented in the above point
\textbf{Circuit and gates}. For the preparation phase, I am still
unaware as to where the problem lies.

\paragraph{Optimizations:} There is a few optimizations that would be
interesting to include. The first is being able to generate triples in
parallel whereas I can only do this sequentially by now. Since it does
not affect the communication cost it was not of high priority in the
project. The same goes for the random double-shares which should
happen in parallel in \texttt{GenerateTriples}, but as of now is done
sequentially.  

A second possible optimization is one that \cite{mpc1} suggests
themselves. It is possible to make the input in the computation phase
linear by using broadcast combined with player elimination, thus
making use of the same trick as with the preparation phase where we
turn detectable protocols into robust protocols, only here it would
not reveal the input of the users as this would not be very
secure. you still deal with the difference between your secret input
and a random value, but this random value is not revealed as part of
the player elimination. Thus your input is kept safe, even if
everything is revealed. This would have been interesting to implement
too, but since it also required an implementation of a consensus
protocol and did not have a great impact on the communication cost
unless you have to input quite a lot of values, I chose to focus my
time on more important issues.
